ETSITS129 211 ve.zo 



(2005-09) 



Technical Specification 



Universal Mobile Telecommunications System (UMTS); 

Rx Interface and Rx/Gx signalling flows 
(3GPP TS 29.211 version 6.2.0 Release 6) 



3ji^ 





3GPP TS 29.21 1 version 6.2.0 Release 6 1 ETSI TS 1 29 21 1 V6.2.0 (2005-09) 



Reference 



RTS/TSGC-03292 11 v620 
Keywords 



UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2005. 
All rights reserved. 

DECT'^", PLUGTESTS™ and UMTS™ are Trade IVlarks of ETSI registered for the benefit of its IVIembers. 
TIPHON^" and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



3GPP TS 29.21 1 version 6.2.0 Release 6 2 ETSI TS 1 29 21 1 V6.2.0 (2005-09) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 29.21 1 version 6.2.0 Release 6 3 ETSI TS 1 29 21 1 V6.2.0 (2005-09) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 5 

1 Scope 6 

2 References 6 

3 Definitions and abbreviations 6 

3.1 Definitions 6 

3.2 Abbreviations 7 

4 Rx reference point 7 

4.1 Overview 7 

4.2 Rx reference model 8 

4.3 Functional elements and capabilities 9 

4.3.1 Charging Rules Function (CRF) 9 

4.3.2 Application Function (AF) 9 

5 FBC Procedures over Rx 9 

5.1 CRF 9 

5.1.1 Initial Provision of Session Information 9 

5.1.2 Modification of Session Information 9 

5.1.3 FBC Gate function 10 

5.1.4 AF Session Termination 10 

5.1.5 Bearer Release 10 

5.1.6 Other Bearer Events 10 

5.2 AF 10 

5.2.1 Provision of Service Information at session establishment 10 

5.2.2 Session modification 1 

5.2.3 FBC Gate function 1 

5.2.4 Void 1 

5.2.5 AF Session Termination 1 

5.2.6 Bearer Release 1 

5.2.7 Other Bearer Events 1 

6 Binding the AF Session Information to the Bearers 11 

7 Rx Protocol 12 

7.1 Protocol Support 12 

7.1.1 Advertising application support 12 

7.1.2 Experimental-Result-Code AVP values 13 

7.2 Securing Diameter messages 13 

7.3 Rx messages 13 

7.3.1 AA-Request (AAR) command 13 

7.3.2 AA- Answer (AAA) command 13 

7.3.3 Re-Auth-Request (RAR) command 14 

7.3.4 Re-Auth-Answer (RAA) command 14 

7.3.5 Session-Termination-Request (STR) command 14 

7.3.6 Session-Termination- Answer (STA) command 15 

7.3.7 Abort-Session-Request (ASR) command 15 

7.3.8 Abort-Session- Answer (ASA) command 15 

7.4 Re-used AVPs for Rx Protocol 15 

8 Rx/Gx Signalling Flows 17 

8.1 AF session establishment or modification 17 

8.2 Request of Charging Rule 19 

8.3 Removal of Charging Rules at AF session release 21 

8.4 Bearer Release 22 



£75/ 



3GPP TS 29.21 1 version 6.2.0 Release 6 4 ETSI TS 1 29 21 1 V6.2.0 (2005-09) 

Annex A (normative): Support for SIP forking 26 

A.l Resources for early media for forked responses 26 

A.2 Updating the Charging Rules information at the final answer 26 

Annex B (informative): Change history 27 

History 28 



£75/ 



3GPP TS 29.21 1 version 6.2.0 Release 6 5 ETSI TS 1 29 21 1 V6.2.0 (2005-09) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document provides the stage 3 specification of the Rx reference point interface. 

The functional requirements and the stage 2 specifications of the Rx reference point are contained in 3GPP TS 23.125 
[2]. The Rx reference point is used to exchange Flow Based Charging information between the Charging Rules 
Function (CRF) and the Application Function (AF). 

Whenever it is possible the present document specifies the protocol by reference to specifications produced by the IETF 
within the scope of Diameter and to the Gq specification 3GPP TS 29.209 [4]. 

The present specification also provides detailed signalling flows for FBC procedures over the interfaces that correspond 
to Rx and Gx reference points. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.125: "Overall high level functionality and architecture impacts of flow based 

charging; Stage 2". 

[3] 3GPP TS 29.210: "Charging rule provisioning over Gx interface". 

[4] 3GPP TS 29.209: "Policy control over Gq interface". 

[5] IETF RFC 3588: "Diameter Base Protocol". 

[6] 3GPP TS 33.210: "3G Security; Network Domain Security (NDS); IP network layer security". 

[7] IETF RFC 4005 : "Diameter Network Access Server Application" . 

[8] IETF RFC 4006: "Diameter Credit Control Application" . 

[9] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

3 Definitions and abbreviations 
3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and 3GPP TS 23.125 
[2] and the following apply: 

Application Function (AF): element offering application(s) that use IP bearer resources. 

NOTE: One example of an AF is the P-CSCF of the IM CN subsystem. 
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AF Session: an application level session established by an application level signalling protocol offered by the AF that 
requires a session set-up with explicit session description before the use of the service. 

NOTE: One example of an application session is an IMS session. 
Attribute-Value Pair (AVP): See RFC 3588 [5], corresponds to an Information Element in a Diameter message. 
Binding: the CRF process of associating IP flows described in AF Service Information with bearers. 

IP flow: a unidirectional flow of IP packets with the same source IP address and port number and the same destination 
IP address and port number and the same transport protocol. Port numbers are only applicable if used by the transport 
protocol. 

Packet Flow: a specific user data flow carried through the Traffic Plane Function. A Packet Flow can be an IP flow. 

Service Information: The set of information conveyed from the AF to the CRF over the Rx interface to be used as a 
basis for Flow Based Charging decisions at the CRF, including information about the AF session (e.g. application 
identifier, type of media, bandwidth, IP address and port number) and parameters controlling the CRF behavior. The 
encoding of the Service Information is provided in 3GPP TS 29.209 [4]. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply: 

AAA AA-Answer 

AAR AA-Request 

AF Application Function 

ASA Abort-Session-Answer 

ASR Abort-Session-Request 

AVP Attribute-Value Pair 

CCA Credit-Control-Answer 

CCR Credit-Control-Request 

CRF Charging Rules Function 

FBC Flow Based Charging 

lANA Internet Assigned Numbers Authority 

IM IP Multimedia 

RAA Re-Auth-Answer 

RAR Re-Auth-Request 

STA Session-Termination-Answer 

STR Session-Termination-Request 

TPF Traffic Plane Function 



Rx reference point 



4.1 Overview 

The Rx interface is used to exchange Flow Based Charging control information between the Charging Rules Function 
(CRF) and the Application Function (AF). As defined in the stage 2 specifications (3GPP TS 23.125 [2]), this 
information is used by the CRF for the Flow Based Charging (FBC) decisions. The CRF exchanges the Flow Based 
Charging control information with the Traffic Plane Function (TPF) as specified in 3GPP TS 29.210 [3]. 

The Rx interface may be an intra- or inter-domain interface. One CRF shall be able to serve more than one AF and one 
given AF may interact with a number of CRFs, although on an AF session basis, it shall interact with only a single CRF. 
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Signalling flows related to the both Rx and Gx interfaces are specified in clause 8 in this specification. 



4.2 



Rx reference model 



The Rx interface is defined between the CRF and the AF. The CRF is in the same PLMN as the TPF. The relationships 
between the different functional entities involved are depicted in figure 4.1a and 4.1b.. 
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Figure 4.1a: Rx interface architecture model for service data flow based online bearer charging 
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Figure 4.1b: Rx interface architecture model for service data flow based offline bearer charging 
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4.3 Functional elements and capabilities 

4.3.1 Charging Rules Function (CRF) 

The Charging Rules Function provides Service Data Flow level Charging Rules to the TPF and informs AF about 
bearer session events. The CRF makes the Charging Rule decisions which may be based on the session and media 
related information obtained from the AF via the Rx reference point, the bearer and subscriber related information 
obtained from the TPF over the Gx reference point, and subscriber and service related data the CRF may be aware of 
The CRF shall provision Charging Rules the TPF via the Gx reference point. The CRF may also provide policy control 
like functions based on Charging Rules provisioning to the TPF. 

The CRF reports, via the Rx reference point, bearer events from the TPF to the AF, e.g. bearer release and bearer 
establishment. 

4.3.2 Application Function (AF) 

The AF is an element offering applications that require the Flow Based Charging of IP bearer resources (e.g. UMTS PS 
domain/GPRS domain resources). One example of an application function is the P-CSCF. The AF shall use the Rx 
reference point to provide session information to the CRF. 



FBC Procedures over Rx 



5.1 CRF 

5.1 .1 Initial Provision of Session Information 

When receiving an initial AA-Request from the AF, the CRF shall check if it contains the Media-Component- 
Description Attribute-Value Pair(s) (AVP(s)) and if so, the CRF shall store the received Service Information. 

If the Specific Action AVP is present in the AAR command the CRF shall store the requested notification for the 
related bearers. 

The CRF shall check whether the received Service Information requires Charging Rules to be provisioned towards 
existing bearer(s). The CRF identifies suitable bearers using the binding mechanisms described in clause 6. 

If the CRF identifies that Charging Rules need to be provisioned, the CRF shall immediately send a Diameter RA- 
Request to the TPF for each of the affected bearer(s) to trigger the TPF to request Charging Rules using a Diameter CC- 
Request. The CRF shall provide the Charging Rules to the TPF within the CC-Answer. 

The CRF shall then send an AA Answer back to the AF. If the CRF needs to terminate the Rx session before it has sent 
the AA Answer, the CRF shall send the AA Answer immediately and before the AS Request. 

5.1 .2 Modification of Session Information 

If the AA-Request from the AF is received for a Diameter session already active (due to an AF session modification), 
the CRF shall update the Service Information with the new information received. Due to the updated Service 
Information, the CRF may send a Diameter RA-Request to the TPF for each of the affected bearer(s) to trigger the TPF 
to request Charging Rules using a Diameter CC-Request. The CRF shall use the CC-Answer to install new Charging 
Rules and/or, to modify or remove the currently installed Charging Rules as required due to the updated Service 
Information. The CRF shall then send an AA Answer back to the AF. If the CRF needs to terminate the Rx session 
before it has sent the AA Answer, the CRF shall send the AA Answer immediately and before the AS Request. 
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5.1.3 FBC Gate function 

The AF may indicate to the CRF as part of the Media-Component-Description AVP(s) whether the IP flows should be 
enabled or disabled at the bearer level. The CRF may receive a separate AA-Request message(s) from the AF to enable 
or disable IP flows based on the received Service Information, the CRF may decide to install or remove the 
corresponding Charging Rule(s). 

5.1 .4 AF Session Termination 

The CRF may receive a ST-Request from the AF, indicating an AF session termination. If any Charging Rules have 
been provisioned for the corresponding Service Data Flow(s), the CRF shall immediately send a Diameter RA-Request 
to the TPF for each of the affected bearer(s) to trigger the TPF to request Charging Rules using Diameter CC-Request. 
The CRF shall use the CC-Answer to remove those Charging Rules from the TPF. 

5.1.5 Bearer Release 

If the CRF receives a CC-Request from the TPF with an indication of bearer termination, the CRF shall check for each 
of the IP flows from AF Service Information bound to this bearer, if it needs to notify the corresponding AF. The CRF 
shall notify the AF if, and only if, the IP flow is no longer bound to any existing bearer. The CRF shall use the 
following procedures to notify the AF: 

If the CRF needs to notify the AF for all IP flows of an AF session, the CRF shall send a Diameter AS-Request. 
The AF will terminate the corresponding Diameter session at the Rx interface using a Diameter ST-Request. 

If the CRF needs to notify the AF for some, but not all, IP flows of an AF session, the CRF shall send an 
Diameter RA-Request. Within the RA-Request, the CRF shall set the value for the Specific-Action AVP to 
INDICATION_OF_TERMINATION_OF_BEARER, shall indicate the affected IP flows with the Flows AVP(s) 
and shall provide the appropriate Abort-Cause AVP value. 



5.1 .6 Otiner Bearer Events 

If CRF receives a notification that a bearer is being established via the Gx interface and the CRF binds IP flow(s) 
described in the Service Information of an AF session to this bearer, and if the corresponding AF has requested a 
notification of bearer establishment from the CRF, the CRF shall send a RA-Request including the Specific Action 
AVP with the value set to INDICATION_OF_ESTABLISHMENT_OF_BEARER and shall indicate the affected IP 
flows with the Flows AVP(s) if not all IP flows within an AF session are affected. 

NOTE: If the IP flow is being bound to several bearers, the AF will receive several of such notifications. 



5.2 AF 

5.2.1 Provision of Service Information at session establishment 

When a new AF session is being established and media information for this AF session is available at the AF, the AF 
shall send the corresponding Service Information to the CRF by sending the AA-Request message. The AF shall 
include the corresponding Media-Component-Description AVP(s) into the message. The AF may include the Flow- 
Grouping AVP(s) to indicate a particular way on how the IP flows described within the service description are 
distributed to several bearers at the bearer establishment. The AF may also include the Specific-Action AVP to request 
notification for certain bearer events, e.g., bearer termination or bearer establishment. To allow the CRF to match the 
described service IP flows in an unambiguous manner with TFT filter information, the AF should supply both source 
and destination IP addresses and port numbers within the Flow-Description AVP, if such information is available. 

The behaviour when the AF does not receive the AAA, or when it arrives after the internal timer waiting for it has 
expired, or when it arrives with an indication different than DIAMETER_SUCCESS, are outside the scope of this 
specification and based on operator policy. 
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5.2.2 Session modification 

During the AF session modification, the AF shall send an update for the session description information to the CRF. 
The AF does this by sending the AA-Request message containing the Media-Component-Description AVP(s) 
containing the updated Service Information. 



5.2.3 FBC Gate function 

The AF shall indicate to the network as part of the Media-Component-Description whether the media IP flow(s) should 
be enabled or disabled at the bearer level. Depending on the application, the AF may instruct the CRF also during the 
session when the IP flow(s) are to be enabled or disabled to pass through the access network. The AF does this by 
sending the AA-Request message containing the Media-Component- Description AVP(s) that contains the flow status 
information for the flows to be enabled or disabled. 

5.2.4 Void 

5.2.5 AF Session Termination 

When an AF session is terminated, the AF shall send Session-Termination-Request message to the CRF. 

5.2.6 Bearer Release 

Upon the reception of a Re-Auth-Request including an Abort-Cause AVP indicating that some of the IP flows (included 
in the Flows AVP) of the AF session are being discontinued (typically PDP_CONTEXT_RELEASE cause), the AF will 
issue a Re-Auth- Answer as a response to the CRF. 

5.2.7 Otiner Bearer Events 

Upon the reception of a Re-Auth-Request including an Specific Action AVP indicating bearer establishment the AF 
will issue a Re-Auth- Answer as a response to the CRF. 



6 Binding the AF Session Information to the Bearers 

Binding refers to the CRF process of associating IP flows described in AF Service Information with bearers. The 
association of IP flows with bearers shall reflect in which bearers an IP flow may be transported. An IP flow described 
in the AF session information can be bound to multiple bearers, as the CRF does not necessarily know which bearer is 
transporting this IP flow. 

NOTE: IP flows described in many AF sessions may share the same bearer(s). Separate IP flows of a single AF 
session may be transported over different bearers. 

If an IP flow described in the AF Service Information is bound to a bearer, the CRF shall install a Charging Rule for 
this bearer with a Service Data Flow Filter matching this IP flow. 

NOTE: The CRF process of deriving Charging Rules from AF service information and Gx information about 

bearer(s) depends on operator preferences and is not fully specified, but the binding of IP flows to bearers 
can be taken into consideration. This does not preclude that a Charging Rule installed at a bearer also 
contains Service Data Flow Filter(s) matching IP flow(s) not bound to this bearer, e.g. if a single 
Charging Rule is used for multiple IP flows of the same service bound to different bearers. 

Upon the release of a bearer or other bearer events, the CRF notifies AF(s) about IP flows bound to this bearer, as 
described in Clauses 5.1.5 and 5.1.6. 
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The following methods for binding are available: 

For all bearer types, the UE IP Address shall be used for binding purposes. For IPv6, if the CRF is only notified 
about the address prefix at the Gx interface, it shall compare this prefix with the prefix of the UE IP address 
provided at the Rx interface. 

For all bearer types, other UE identity information (e.g. IMSI or MSISDN) may be used for binding purposes if 
the AF provided such information. 

In particular, for GPRS, it is also recommended to use TFT filters (from TPF via Gx) and Flow-Description 
AVPs provided within the service information (from AF via Rx) to select the Changing Rules matching to a PDP 
context. The flow grouping AVP(s) of the Service Information may be used for further analysis. 

Also for GPRS, the QoS information (negotiated QoS from the TPF and QoS information derived from the 
service information provided by the AF) may be used for further analysis. 

The GPRS binding mechanism does not necessarily identify a single PDP context for an IP flow described in AF 
Service Information, therefore the same Charging Rule may be installed over several PDP contexts, even if it 
corresponds only to a single AF session IP flow. 



7 Rx Protocol 

7.1 Protocol Support 

The Rx reference point shall be based on Gq protocol as specified in 3GPP TS 29.209 [4]. Most of the AVPs from the 
Gq protocol are reused as specified in sub-clause 7.2. 

Editor's note: The new application id needs to be allocated for Rx Protocol from lANA. 

The Rx application is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor 
identifier assigned by lANA to 3GPP ( http://www.iana.org/assignments/enterprise-numbers ) is 10415. 

Due to the definition of the commands used in Rx protocol, there is no possibility to skip the Auth- Application-Id 
AVP and use the Vendor-Specific-Application-Id AVP instead. Therefore the Rx application identification shall be 
included in the Auth- Application-Id AVP. 

With regard to the Diameter protocol defined over the Rx reference point, the CRF acts as a Diameter server, in the 
sense that it is the network element that handles Charging Rule control for a particular realm. The AF acts as the 
Diameter Client, in the sense that is the network element requesting FBC control in the bearer path network resources. 

The support of Diameter agents between the CRF and the AF, is optional for the IMS, where the Rx is intra operator 
i.e. for GPRS: TPF, CRF and P-CSCF are all in the same network. 

7.1 .1 Advertising application support 

The AF and the CRF shall advertise the support of the Rx specific Application by including the value of the application 
identifier in the Auth-Application-Id AVP and the value of the 3GPP (10415) in the Vendor-Id AVP of the 
Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands as specified in RFC 3588 [4], i.e. as part 
of the Vendor-Specific-Application-Id AVP. The Capabilities-Exchange-Request and Capabilities-Exchange-Answer 
commands are specified in the Diameter Base Protocol. 
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7.1 .2 Experimental-Result-Code AVP values 

The specific Experimental-Result-Code AVP values used by Rx protocol are the same as used by Gq protocol. These 
values shall be used as specified by Gq protocol in 3GPP TS 29.209 [4]. 

7.2 Securing Diameter messages 

For secure transport of Diameter messages, see 3GPP TS 33.210 [6]. 

7.3 Rx messages 

Existing Diameter command codes from the Diameter base protocol RFC 3588 [5] and the NASREQ Diameter 
application (IETF RFC 4005 [7]) are used with the Rx specific AVPs. An Rx specific Auth- Application id is used 
together with the command code to identify the Rx messages. 

NOTE: The notion of NAS (Network Access Server) is not used here, NASREQ is just used for protocol 
purposes, not for its functional meaning. 

NOTE: Some of the AVPs included in the messages formats below are in bold to highlight that these AVPs are 
used by this specific protocol and do not belong to the original Diameter Base Protocol RFC 3588 [5]. 



7.3.1 AA-Request (AAR) command 



The AAR command, indicated by the Command-Code field set to 265 and the 'R' bit set in the Command Flags field, is 
sent by an AF to the CRF in order to provide it with the Session Information. 

Message Format: 



<AA-Request> ::= < Diameter Header: 265, REQ, PXY > 
< Session-Id > 

Auth-Application-Id } 
Origin-Host } 
Origin-Realm } 
Destination-Realm } 
Media-Component-Description ] 
Flow-Grouping ] 
AF-Charging-Identifier ] 
SIP-Forking-Indication ] 
Specific-Action ] 
Subscript ion- ID ] 
Proxy-Info ] 
Route-Record ] 
AVP ] 



7.3.2 AA-Answer (AAA) command 



The AAA command, indicated by the Command-Code field set to 265 and the 'R' bit cleared in the Command Flags 
field, is sent by the CRF to the AF in response to the AAR command. 

Message Format: 



<AA-Answer> ::= < Diameter Header: 265, PXY > 
< Session-Id > 

Auth-Application-Id } 
Origin-Host } 
Origin-Realm } 
Result-Code ] 
Experimental-Result ] 
Error-Message ] 
Error-Reporting- Host ] 
Failed-AVP ] 
Proxy-Info ] 
AVP ] 
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7.3.3 Re-Auth-Request (RAR) command 



The RAR command, indicated by the Command-Code field set to 258 and the 'R' bit set in the Command Flags field, is 
sent by the CRF to the AF in order to indicate an Rx specific action. 

The values INDICATION_OF_ESTABLISHMENT_OF_BEARER and INDICATION_OF_RELEASE_OF_BEARER 
of the Specific-Action AVP are the only ones used in for Rx. These values of the Specific-Action AVP shall not be 
combined with each other in a Re-Auth-Request. 



Message Format: 



<RA-Request> 



< Diameter Header: 258, REQ, PXY > 

< Session-Id > 
Origin-Host } 
Origin-Realm } 
Destination-Realm } 
Destination-Host } 
Auth-Application-Id } 
Specific-Action ) 
Flows ] 

Subscript ion- ID ] 
Abort-Cause ] 
Origin-State-Id ] 
Proxy-Info ] 
Route-Record ] 
AVP ] 



7.3.4 Re-Auth-Answer (RAA) command 



The RAA command, indicated by the Command-Code field set to 258 and the 'R' bit cleared in the Command Flags 
field, is sent by the AF to the CRF in response to the RAR command. 



Message Format: 



<RA-Answer> 



< Diameter Header; 258, 

< Session-Id > 
Origin-Host } 
Origin-Realm } 
Result-Code ] 
Experimental-Result ] 
Origin-State-Id 1 
Error-Message ] 
Error-Reporting- Host 
Failed-AVP ] 
Proxy-Info ] 
AVP 1 



7.3.5 Session-Termination-Request (STR) command 

The STR command, indicated by the Command-Code field set to 275 and the 'R' bit set in the Command Flags field, is 
sent by the AF to inform the CRF that an established session shall be terminated. 

Message Format: 



CST-Request; 



Diameter Header: 275, REQ, PXY 
Session-Id > 
Origin-Host } 
Origin-Realm } 
Destination-Realm } 
Auth-Application-Id } 
Termination-Cause } 
Destination-Host ] 
Class ] 

Origin-State-Id ] 
Proxy-Info ] 
Route-Record ] 
AVP ] 
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7.3.6 Session-Termination-Answer (STA) command 

The STA command, indicated by the Command-Code field set to 275 and the 'R' bit cleared in the Command Flags 
field, is sent by the CRF to the AF in response to the STR command. 



Message Format: 



<ST-Answer> 



Diameter Header: 275, PXY > 
Session-Id > 
Origin-Host } 
Origin-Realm } 
Result-Code ] 
Experimental-Result ] 
Error-Message ] 
Error-Reporting-Host ] 
Failed-AVP ] 
Origin-State-Id ] 
Redirect-Host ] 
Redirect-Host-Usage ] 
Redirect-Max-Cache-Time ] 
Proxy-Info ] 
AVP ] 



7.3.7 Abort-Session-Request (ASR) command 

The ASR command, indicated by the Command-Code field set to 274 and the 'R' bit set in the Command Flags field, is 
sent by the CRF to inform the AF that bearer for the established session is no longer available. 



Message Format: 



<AS-Request> 



< Diameter Header: 274, REQ, PXY > 

< Session-Id > 
Origin-Host } 
Origin-Realm } 
Destination-Realm } 
Destination-Host } 
Auth-Application-Id } 
Abort-Cause ) 
Origin-State-Id ] 
Proxy-Info ] 
Route-Record ] 

AVP ] 



7.3.8 Abort-Session-Answer (ASA) command 

The ASA command, indicated by the Command-Code field set to 274 and the 'R' bit cleared in the Command Flags 
field, is sent by the AF to the CRF in response to the ASR command. 



Message Format: 



<AS-Answer> 



Diameter Header: 274, PXY 
Session-Id > 
Origin-Host } 
Origin-Realm } 
Result-Code ] 
Experimental-Result ] 
Origin-State-Id ] 
Error-Message ] 
Error-Reporting-Host ] 
Failed-AVP ] 
Redirected-Host ] 
Redirected-Host-Usage ] 
Redirected-Max-Cache-Time 
Proxy-Info ] 
AVP ] 



7.4 



Re-used AVPs for Rx Protocol 



The table 7.3.1 lists the Diameter AVPs re-used by the Rx reference point from existing Diameter Applications, 
including a reference to their respective specifications and when needed, a short description of their usage within the Rx 
reference point. Other AVPs from existing Diameter Applications, except for the AVPs from Diameter Base Protocol, 
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do not need to be supported. The AVPs from Diameter Base Protocol are not included in table 7.3.1, but they are re- 
used for the Rx protocol 

The Vendor-Id header of all AVPs defined in the present document shall be set to 3GPP (10415). 

Table 7.3.1 : Rx re-used Diameter AVPs 



Attribute Name 


Reference 


Comments 


Abort-Cause 


3GPP TS 29.209 [4] 




AF- Application-Identifier 


3GPP TS 29.209 [4] 




AF-Charging-Identifier 


3GPP TS 29.209 [4] 




Flow-Description 


3GPP TS 29.209 [4] 




Flow-Number 


3GPP TS 29.209 [4] 




Flows 


3GPP TS 29.209 [4] 




Flow-Status 


3GPP TS 29.209 [4] 




Flow-Usage 


3GPP TS 29.209 [4] 




Flow-Grouping 


3GPP TS 29.209 [4] 




Max-Requested-Bandwidth-DL 


3GPP TS 29.209 [4] 




Max-Requested-Bandwidth-UL 


3GPP TS 29.209 [4] 




Media-Component-Description 


3GPP TS 29.209 [4] 




Media-Component-Number 


3GPP TS 29.209 [4] 




Media-Sub-Component AVP 


3GPP TS 29.209 [4] 




Media-Type 


3GPP TS 29.209 [4] 




RR-Bandwidth 


3GPP TS 29.209 [4] 




RS -Bandwidth 


3GPP TS 29.209 [4] 




SIP-Forking-Indication 


3GPP TS 29.209 [4] 




Specific-Action 


3GPP TS 29.209 [4] 


Allowed values: 

INDICATION_OF_ 
TERMINATION_OF_BEARER(4) 

INDICATION_OF_ESTABLISMENT 
OF BEARER (5) 


Subscription-Id 


RFC 4006 [8] 


The identification of the subscription 
(IMSI, MSISDN, etc.) 



£75/ 



3GPP TS 29.21 1 version 6.2.0 Release 6 1 7 ETSI TS 1 29 21 1 V6.2.0 (2005-09) 

8 Rx/Gx Signalling Flows 

The signaling flows in this Clause are examples. 

8.1 AF session establishment or modification 

This clause covers the provision of Service Information and related Charging Rules when an AF session is being 
established or modified. 



£75/ 



3GPP TS 29.21 1 version 6.2.0 Release 6 



18 



ETSI TS 129 211 V6.2.0 (2005-09) 



TPF 



CRF 



AF 



1 . Trigger 



2. Define service information 



3. Diameter AAR 



4. Store Service Information 



I 



5. Identify affected bearer(s) 



6. Diameter RAR 



7. Diameter RAA 



8. CRF-initiated Cliarging Rule Request, figure 8.2 starting with step 2. 



For each 
affected bearer 



9. Diameter AAA 



Legend: 



-► Mandatory 
-► Conditional 



The AF receives an internal or external trigger to provide Service Information, at a set-up of a new AF 

session or at a modification of an existing AF session. 

The AF identifies the Service Information needed (e.g. IP address of the IP flow(s), port numbers to be 

used etc.). 

The AF provides the Service Information to the CRF by sending a Diameter AAR for a new Rx Diameter 

session at set-up of a new AF session, or for the existing Rx Diameter session in case of AF session 

modification. 

The CRF shall store the received Service Information 

The CRF identifies any affected established bearer(s) by binding new or modified IP flows described in the 

AF Service Information to bearer(s) using the bearer information previously received from the TPF and the 

Service Information received from the AF. 



If any affected bearer(s) are identified in step 5, steps 6, 7 and 8 are performed separately for each of these 
bearer(s). If there are no bearer(s) affected, steps 6, 7 and 8 are not executed. 

6. The CRF sends Diameter RAR to trigger the TPF to request Charging Rules. 

7. The TPF sends RAA to acknowledge the RAR. 

8 The TPF will request Charging Rules for the bearer identified in step 7, as described in Figure 8.2 starting 

with step 2. 

9. As soon as the CRF completes the provisioning of Charging Rules for the bearer(s) identified in step 5, the 

CRF sends a Diameter AAA to the AF. 

Figure 8.1 : AF session establishment or modification 
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8.2 Request of Charging Rule 

This clause covers two cases: 

A bearer-event-initiated Request of Charging Rules occurs when a new bearer is established or when an existing 
bearer is modified. For GPRS, these are PDP Context Activation(s) or Modification(s). A bearer modification 
triggers a Charging Rule request only if the CRF has previously requested a Charging Rule Request for the given 
bearer modification event. 

A CRF-initiated Request of Charging Rules is triggered by a Diameter RAR sent from the CRF to solicit a 
Request of Charging Rules from the TPF. The RAR request may occur in several scenarios, as depicted in 
Figures 8.1 - 8.4. A CRF-initiated Request of Charging Rules may also happen as a consequence of a bearer- 
event-initiated Request of Charging Rules, as shown in figure 8.2. 
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TPF 



CRF 



1 . Trigger 



2. Diameter CCR 



3. Store Bearer Information 



4. Bind bearer session to any 
existing AF session(s) 



5. Charging Rules Decision 



6. Store Charging Rules 



7. Diameter CCA 



8. Update Charging Rules 



11. Diameter RAR 

12. Diameter RAA 



9. Diameter RAR 



10. Diameter RAA 



AF 



Only for bearer establishment: 
For each affected AF session, if 
-^AF has requested a notification 
of bearer establishment 



^ 



13. CRF-initiated Charging Rule Request, this figure starting with step 2 



For each affected bearer, if IP 
P"Flow(s) were possibly moved 
to other bearer(s) 













Legend: 


Mandatory 
Conditional 






-► 









1 . The TPF receives a trigger for a Charging Rule Request, such as the establishment or modification of a 
bearer or an RAR from the CRF. 

2. The Charging Rules are requested by the TPF, using the Diameter CCR. The TPF also provides 
information about the bearer within the request. 
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3. The CRF stores the received bearer information in the Diameter CCR, e.g. TFT filters and UE IP address 
(prefix). 

4. The CRF binds the bearer to all matching IP flow(s) of existing of AF session(s) using the bearer 
information received from the TPF and the Service Information received from the AF(s). 

5. The CRF defines new Charging Rule(s) to be installed for the identified bearer. For a modified bearer, the 
CRF can also identify existing Charging Rules that need to be modified or removed. The Charging Rules 
may relate to any of the matching AF sessions identified in step 4 or that may exist in the CRF without 
matching to any AF session. 

6. The CRF stores the selected Charging Rules for the bearer. 

7. The Charging Rules are provisioned by the CRF to the TPF using Diameter CCA. The CRF may also 
provide event triggers listing bearer events for which the CRF desires Charging Rule Requests. 

8. The TPF installs the received Charging Rules. For a modified bearer the TPF may also have to modify or 
remove previously installed Charging Rules. 

If the trigger in step 1 was a bearer establishment, steps 9 and 10 are executed separately for each affected AF 
session for which the AF has requested notification of bearer establishment. 

9. The CRF sends a Diameter RAR to the AF to inform it about the bearer establishment. 

1 0. The CRF sends RAA to acknowledge the RAR. 

If IP flow(s) were possibly moved to other bearer(s), other bearer(s) may need to be modified. The following steps are 
performed for each of these bearers. For GPRS, an IP flow may be possibly moved if a higher priority TFT filter in the 
modified PDP context was removed and a lower priority TFT filter in another PDP context matches the IP flow. 

1 1 . The CRF sends Diameter RAR to trigger the TPF to request Charging Rules for the other bearer. 

1 2. The TPF sends RAA to acknowledge the RAR. 

13. The TPF will request Charging Rules for the bearer identified in step 1 1 , as described in the present figure 
starting with step 2. 

Figure 8.2: Charging Rule Request. 

8.3 Removal of Charging Rules at AF session release 

This clause covers the removal of Charging Rules at the AF session release. 



£75/ 



3GPP TS 29.21 1 version 6.2.0 Release 6 



22 



ETSI TS 129 211 V6.2.0 (2005-09) 



TPF 



CRF 



AF 



1 . Trigger 



2. Diameter STR 



3. Identify the affected 
bearers where charging 
rule(s) need to be removed 



4. Diameter RAR 



5. Diameter RAA 



I 6. CRF-initiated Charging Rule Request, figure 8.2 starting with step 2. 



^ 



> 




For each 
affected bearer 



_y 



Legend: 



-► Mandatory 
-► Conditional 



1 . The AF receives an internal or external trigger for a session release. 

2. The AF sends a session termination request, Diameter STR, to the CRF to request the removal of the 
session. 

3. The CRF identifies the affected bearers where Charging Rules for the IP flow{s) of this AF session are 
installed. These Charging Rules need to be removed. 

If any affected bearer(s) are identified, steps 4, 5 and 6 are performed separately for each of these bearer(s). 

4. The CRF sends a Diameter RAR to trigger the TPF to request Charging Rules. 

5. The TPF sends a Diameter RAA to acknowledge the RAR. 

6. The TPF will request Charging Rules for the bearer identified in step 7, as described in Figure 8.2 starting 
with step 2. The CRF will request the TPF to remove the Charging Rules for the released AF session. 

7. As soon as the CRF has requested the TPF to remove the Charging Rules for all the bearer{s) identified in 
step 3, The CRF sends Diameter STA, session termination answer, to the AF. 



Figure 8.3: Removal of Charging Rules at AF session release 



8.4 



Bearer Release 



This clause covers the bearer release, which may be indicated to the AF. Three cases are covered: 
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bearer release that does not cause IP flow(s) within an AF session to be disabled; 

bearer release that causes at least one but not all the IP flow(s) within an AF session to be disabled and 

bearer release that causes all the IP flows within an AF session to be disabled. 

Bearer release may not cause an IP flow within an AF session to be disabled if the IP flow is bound to more than one 
bearer. For GPRS, those bearers may be PDP context(s) within a PDP session. The CRF does not necessary know 
which PDP context carries the IP flow, thus a release of a PDP context does not necessarily mean that the IP flow is 
disabled. 
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TPF 



CRF 



c 



1 . Bearer release 



J 



2. Diameter CCR 



3. Identify the IP flows 
bound to the bearer. 
Re-evaluate binding . 



4. Diameter CCA 



r 



V 



r 



V 



9. Diameter RAR 

10. Diameter RAA 



5. Diameter ASR 



6. Diameter ASA 



7. Diameter STR 



8. Diameter STA 



5a. Diameter RAR 
6a. Diameter RAA 



7a. Diameter AAR 
8a. Diameter AAA 



AF 



^ 



V If all the IP flows 
f within AF session 
are affected 



J 



^ 



, If not all IP flows 
r within AF session 
are affected 



J 



^ 



. For each 
/^ affected 
bearer 



Legend: 

► 

► 



I 11 . CRF-lnitlated Charging Rule Request, figure 8.2 starting with step 2. 
I I I 

Conditional 
Mandatory 
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1 . A bearer is deactivated. For GPRS, the SGSN deactivates the PDP context carrying IP flow(s) of by 
sending the Delete PDP Context Request message to the GGSN. 

2. The TPF sends a Diameter OCR message to the GRF, indicating bearer termination. 

3. The GRF identifies the IP flows bound to the removed bearer and updates the stored bearer information. 
The GRF re-evaluates the binding of IP flows, as IP flows may now be bound to other bearers. For GPRS, 
an IP flow may be bound to another PDP Context if it was previously bound to the removed PDP context 
due to a higher priority TFT filter, and a lower priority TFT filter in another PDP context matches the IP 
flow. 

4. The GRF acknowledges the bearer termination by sending a Diameter CCA message. 

The following steps 5 to 8 or 5a to 8a apply for the case where at least one IP Flow within an AF session is being 
disabled, i.e. if the IP Flow is not bound to any other bearer that is still established. The steps shall be performed 
separately for each ongoing AF session that is affected by the bearer release as explained below. 

If all IP flow(s) within the AF session are disabled by the bearer release: 

5. The GRF indicates the session abort to the AF by sending a Diameter ASR message to the AF. 

6. The AF responds by sending a Diameter ASA message to the GRF. 

7. The AF sends a Diameter STR message to the GRF to indicate that the session has been terminated. 

8. The GRF responds by sending a Diameter STA message to the AF. 

If at least one but not all of the IP flow(s) within the AF session are disabled by the bearer release, and the AF has 

requested notification of bearer removal: 

5a. The GRF indicates the release of the bearer by sending a Diameter RAR to the AF. 

6a. The AF responds by sending a Diameter RAA to the GRF. 

7a. The AF may send an AAR to the GRF to update the session information. 

8a. If step 7a occurs, the GRF responds by sending a AAA to the AF. 

If IP Flow(s) were bound to other bearer(s). Charging Rules at these bearer(s) may need to be installed or modified. 
The following steps are performed for each of these bearers. For GPRS, an IP flow may be bound to another PDP 
context if it was previously bound to the removed PDP context due to a higher priority TFT filter, and a lower priority 
TFT filter in the other PDP context matches the IP flow. 

9. The GRF sends Diameter RAR to trigger the TPF to request Charging Rules for the other bearer. 

1 0. The TPF sends RAA to acknowledge the RAR. 

1 1 . The TPF will request Charging Rules for the bearer identified in step 9, as described in figure 8.2 starting 
with step 2. 

Figure 8.4: Bearer Release 
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Annex A (normative): 
Support for SIP forking 



The P-CSCF shall be able to handle forking when FBC is applied. Forking can occur as specified in 
3GPPTS 23.228 [9]. 

A.1 Resources for early media for forked responses 

When a SIP session has been originated by a connected UE, the P-CSCF may receive provisional responses associated 
with different early dialogues due to forking before the first final answer is received. Multiple early media session may 
be established during this process. 

The UE and the P-CSCF become aware of the forking only when a subsequent provisional response arrives for a new 
early dialogue. After the first early media session is established, for each subsequent provisional response establishing 
an additional early media session, the P-CSCF shall use an AA-Request within the existing Diameter session containing 
the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES and include the Service Information derived 
from each corresponding provisional response. 

When receiving an AA-Request containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES, the 
CRF shall identify the existing Service Information for the corresponding AF session. The CRF shall send additional 
Charging Rules as required by the Flow Description AVPs within the session information to the TPF.The CRF can also 
use the highest QoS requested for an IP flow by any of the forked responses as the required QoS for that IP flow. 

A.2 Updating the Charging Rules information at the final answer 

The P-CSCF shall store the SDP information for each early dialogue separately until the first final SIP answer is 
received. Then the corresponding early dialogue is progressed to an established dialogue to establish the final SIP 
session. All the other early dialogues are terminated. The Service Information for the SIP session is updated to match 
the requirements of the remaining early dialogue only. 

When receiving the first final SIP response, the P-CSCF shall send an AA-Request without the SIP-Forking-Indication 
AVP and include the Service Information derived from the SDP corresponding to the dialogue of the final response. 

When receiving an AA-Request with no SIP-Forking-Indication AVP or with a SIP-Forking-Indication AVP with value 
SINGLE_DIALOGUE, the CRF shall update the installed Charging Rules information to match only the requirements 
of the Service Information within this AA-Request. The CRF should immediately remove Charging Rule(s) not 
matching IP flow(s) in the updated Service Information, to reduce the risk for initial clipping of the media stream, and 
to minimize possible misuse of resources. 
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